Methods and apparatus for funds remittances to non-payment card accounts using payment card system

ABSTRACT

A method includes receiving a funds transfer request. The request specifies a transaction amount, a destination bank account and a source payment card account. A response to the request includes initiating a payment transaction to transfer the transaction amount from the source payment card account to a payment card system settlement account that was established by a payment card system with an agent bank. The response to the request also includes issuing an instruction for the agent bank to transfer the transaction amount from the settlement account to the destination bank account.

CROSS-REFERENCE TO RELATED APPLICATION

This application claims the benefit of provisional patent applicationSer. No. 60/910,550, filed Apr. 6, 2007, which application isincorporated herein by reference.

BACKGROUND

Embodiments disclosed herein relate to remittance systems. Inparticular, some embodiments relate to methods, apparatus, systems,means and computer program products for implementing a remittance systemon the basis of an international payment card system.

Many individuals regularly send money to family or friends acrossinternational borders. The total annual volume of internationalperson-to-person remittances is measured in the hundreds of billions ofU.S. dollars (including transactions that involve U.S. dollars andtransactions that do not involve U.S. dollars) and is increasing fromyear to year.

Formal commercial remittance channels are generally labor-intensive andexpensive to use. Informal channels for remittances are alsolabor-intensive and may not provide adequate protection for the fundsremitted. Many of the people who make or receive internationalremittances are not wealthy and can ill-afford the costs and riskspresented by conventional remittance channels.

More generally, senders and recipients of remittances frequently findconventional remittance channels to be time-consuming and inconvenient.It is not unusual for the sender to be required to bring cash to a storeoperated by a remittance services provider (RSP). Accordingly, thesender is constrained to accommodate himself or herself to the store'soperating hours, must carry cash on his or her person, and may have towait in line or otherwise experience poor service at the RSP's store.The recipient also may be required to pick up the remitted funds at anRSP's store, thereby possibly suffering the same disadvantages andinconveniences that the sender was subject to.

International remittances also raise issues related to governmentalsecurity and anti-crime interests. In many countries, regulations are inplace with respect to international transfers of funds, to aid inefforts to combat funding of terrorist groups and organized crime. Thereare also international initiatives in these areas. These types ofregulations are generally referred to as “anti-money laundering” (AML)provisions, and typically require that financial institutions and RSPs“know your customer” (KYC). Compliance with KYC and AML regulations mayplace significant cost and administrative burdens on formalinternational remittance channels. Of course, these costs are passed onto the users of the remittance channels.

In U.S. patent application Ser. No. 11/836,984 (which has a commoninventor herewith, and which is incorporated herein by reference), aninternational remittance system was proposed that is based on aninternational payment card system such as that operated by MasterCardInternational Inc. (the assignee hereof) and its member financialinstitutions. Aspects of the present disclosure extend the benefits ofsuch a system to remittance recipients who do not have payment cardaccounts.

The present disclosure, in other aspects, addresses issues that mayarise related to encouraging participation by payment card accountissuing financial institutions in an international remittance system. Inparticular, the present disclosure proposes web-based software toolsthat make it convenient for participating financial institutions toperform administrative tasks involved in implementing policy decisionsrelated to participation in such a remittance system.

BRIEF DESCRIPTION OF THE DRAWINGS

Features and advantages of some embodiments of the present invention,and the manner in which the same are accomplished, will become morereadily apparent upon consideration of the following detaileddescription of the invention taken in conjunction with the accompanyingdrawings, which illustrate preferred and exemplary embodiments and whichare not necessarily drawn to scale, wherein:

FIG. 1 is a block diagram that illustrates an international remittancesystem provided according to some aspects of the present invention.

FIG. 2 is a block diagram that illustrates a system of computersoperated in connection with administrative aspects and other aspects ofthe remittance system of FIG. 1 and provided according to other aspectsof the present invention.

FIG. 3 is a block diagram that illustrates an embodiment of a servercomputer that may be part of the system of FIG. 2.

FIG. 4 is a block diagram that illustrates an embodiment of anotherserver computer that may be part of the system of FIG. 2.

FIGS. 5-9 are screen displays that may be provided by the servercomputer of FIG. 3 to aid in administrative set-up procedures performedby a financial institution which participates in an internationalremittance system.

FIG. 10 is a flow chart that illustrates an administrative set-upprocedure that may be performed by a financial institution whichparticipates in an international remittance system.

FIGS. 11-14 are screen displays that may be provided by the servercomputer of FIG. 3 in conjunction with the procedure illustrated by FIG.10.

FIG. 15 is a flow chart that illustrates another administrative set-upprocedure that may be performed by a financial institution whichparticipates in an international remittance system.

FIGS. 16-24 are screen displays that may be provided by the servercomputer of FIG. 3 in conjunction with the procedure illustrated by FIG.15.

FIGS. 25-30 are screen displays that may be provided by one or morecomputers included in the system of FIG. 2 in connection with otheradministrative aspects of an international remittance system.

FIGS. 31-41 are screen displays presented in the system of FIGS. 1and/or 2 to a customer who wishes to make remittances using theinternational remittance system.

FIG. 42 is a block diagram that illustrates a system in which aninternational payment card system is used to make remittances into bankaccounts that are not payment card accounts.

FIG. 43 is a block diagram that illustrates a server computer that isincluded in the system of FIG. 42 for initiating funds transfers.

FIG. 44 is a block diagram that illustrates a computer that receivesand/or relays funds transfers in the system of FIG. 42.

FIG. 45 is a flow chart that illustrates a process that may be performedby the computer of FIG. 43.

FIG. 46 is a flow chart that illustrates a process that may be performedby the computer of FIG. 44.

FIG. 47 is a flow chart that illustrates a process that may be performedby a financial institution computer in the system of FIGS. 1 and/or 2.

DETAILED DESCRIPTION

In general, and for the purpose of introducing concepts of embodimentsof the present invention, an international remittance system is based ona payment card system such as that operated by MasterCard InternationalInc., the assignee hereof. Remittances are transferred and cleared fromsenders' payment card accounts to recipients' payment card accounts orto recipients' accounts that are not payment card accounts. Financialinstitutions are the issuers of the payment card accounts and handlecompliance with KYC/AML regulations.

In some embodiments, web-based tools provide a convenient vehicle forparticipating financial institutions to implement policy decisionsconcerning, e.g., the levels of service fees and/or foreign exchangefees to be charged in connection with remittances.

Remittance systems such as those described herein may leverage existingpayment systems to provide previously unavailable efficiencies,cost-effectiveness and convenience, while also facilitating regulatorycompliance by participating financial institutions (FIs).

FIG. 1 is a block diagram that illustrates an international remittancesystem 100 provided according to some aspects of the present invention.

At the heart of the remittance system 100 is a payment system 102. Aswill be seen, the payment system 102 operates to route and clear fundstransfers from the payment card accounts of senders to the payment cardaccounts or other accounts of recipients. One example of a suitablepayment system is the Banknet system, which is well-known to those whoare skilled in the art, and which is operated by the assignee hereof.

A major strength of a payment system such as the Banknet system is thatit interlinks numerous financial institutions around the world. Inpractice the remittance system 100 may include many financialinstitutions that act as issuers of payment card accounts, but forpurposes of illustration only two such FIs are shown in FIG. 1, namelythe financial institution (sending FI 104) that issued the payment cardaccount of the sender of a remittance, and the financial institution(receiving FI 106) that issued the payment card account of the recipientof the remittance. (As discussed below in connection with FIG. 42, in analternative embodiment, at least some of the recipients' accounts neednot be payment card accounts.) As indicated respectively at 108 and 110,the sending FI 104 and the receiving FI 106 are both connected bysuitable data communication paths to the payment system 102. It may beassumed that the receiving FI 106 is located in a different country fromFI 104 so that any remittance transmitted between the two FIs 104, 106is an international remittance.

It may also be assumed that the FIs 104, 106, and the other FIs includedin the remittance system 100 but not depicted in the drawings, are banksor other organizations that are subject to regulation to assurecompliance with KYC and AML requirements. It may also be assumed thatthe FIs have internal procedures in place to comply with KYC and AMLrequirements. Consequently, upon or prior to opening a payment cardaccount for a customer, each FI gathers information about the customer,such as the customer's full name, and residential address. Customaryprocedures may also call for the FI to obtain documentary proof of thecustomer information. The documentary proof may be a driver's license, apassport, an identity card, etc. To demonstrate compliance with thedocumentation procedures, the FI may also keep an image of thedocument(s) used to establish the customer's identity and address.

Continuing with the concept that FIG. 1 shows components of theremittance system 100 with respect to a single remittance transaction,block 114 represents a mechanism by which the sender initiates a fundstransfer. The mechanism 114, from which the funds transfer originates,may come in a number of different forms, such as the sender's mobiletelephone, an automatic teller machine (ATM), or a personal computer orother web-browsing device (from which the sender may access a websitemaintained by or on behalf of the sending FI 104). As anotheralternative, the sender may visit a bank branch to initiate the fundstransfer, and may speak with an employee of the sending FI 104. Inresponse to the sender's request, the sending FI employee may operate apersonal computer or terminal to launch the funds transfer.

Also shown in FIG. 1 (in phantom) is a mechanism 116 that may beutilized by the receiving FI 106 to notify that recipient that the fundstransfer has taken place. The notification mechanism may be therecipient's mobile telephone, to which the receiving FI may send a textmessage or automated telephone call. Other possible embodiments of thenotification mechanism may include the recipient's home personalcomputer (by e-mail) or a pager.

FIG. 2 is a block diagram that illustrates a system 200 of computersoperated in connection with administrative aspects and other aspects ofthe remittance system 100 of FIG. 1 and provided according to otheraspects of the present invention. The main focus of the computercapabilities of FIG. 2 is in connection with set-up and transactionhandling at the sending side of an international remittance system suchas that illustrated in FIG. 1.

The system 200 may include a number of computers 202 that are operatedby or on behalf of financial institutions in connection with the sendingof domestic and/or international remittances. Thus, any one or more ofthe computers 202 may serve the role represented by block 104 (sendingFI) in FIG. 1. The number of computers 202 may be large, in that atleast one such computer may be operated by or on behalf of eachfinancial institution that participates as a sending FI in a remittancesystem.

In addition, the system 200 may include a server computer 204 thatprovides one or more web-based tools for use by sending financialinstitutions in implementing remittance services for the customers ofthe sending FIs. As will be seen, in some embodiments, the toolsprovided by the server computer 204 may aid in set-up operations forservice fees and in other administrative functions which a sending FImay need to engage in.

Still further, the system 200 may include a number of user computers206. As will be seen, the user computers may be operated by individualcustomers who wish to make remittances and may be used by theindividuals to access remittance services offered by sending FIs. Ingeneral, each individual customer may have, or wish to establish, abanking relationship with one of the sending FIs referred to above.

Another class of user computers 206 (not separately indicated) may beoperated by administrative personnel who are employed by sending FIs.User computers of this class may be operated to access the servercomputer 204 and/or for other purposes related to the system 200.

The system 200 may also encompass a data communication network 208. Thedata communication network 208 may be formed partly or entirely by apublic network such as the Internet, and/or may be at least partlyconstituted by private data communication channels. The datacommunication network 208 may operate to allow one or more of the othercomponents of the system 200 to communicate with one or more othercomponents of the system 200. For example, data communication over thenetwork 208 may take place between the sending FI computers 202 and theadministrative set-up computer 204 and between the user computers 206and the sending FI computers 202.

Various administrative software tools described below may be hosted atand accessed via the administrative set-up server computer 204 oralternatively may be downloaded from the administrative set-up servercomputer 204 to one or more of the FI remittance host computers 202 anddownloaded from and accessed via the FI remittance host computers 202.Alternatively, administrative settings set-up in the administrativeset-up server computer 204 may be downloaded therefrom to an FIremittance host computer 202 to control operation of the FI remittancehost computer 202. Terminals and/or personal computers operated by FIpersonnel may interact with either or both of the FI's respective hostcomputer 202 and the administrative set-up server computer 204. The FIfunctions and/or set-up functions described herein may be divided in anyconvenient manner between an FI's host computer 202 and theadministrative set-up server computer 204. Moreover the computer 204 maybe combined with at least one of the computers 202.

FIG. 3 is a block diagram that illustrates an embodiment of the servercomputer 204.

The server computer 204 may be conventional in its hardware aspects butmay be controlled by software to cause it to operate in accordance withaspects of the present invention.

The server computer 204 may include a computer processor 300 operativelycoupled to a communication device 301, a storage device 304, an inputdevice 306 and an output device 308.

The computer processor 300 may be constituted by one or moreconventional processors. Processor 300 operates to executeprocessor-executable steps, contained in program instructions describedbelow, so as to control the server computer 204 to provide desiredfunctionality.

Communication device 301 may be used to facilitate communication with,for example, other devices (such as the other computers shown in FIG.2).

Input device 306 may comprise one or more of any type of peripheraldevice typically used to input data into a computer. For example, theinput device 306 may include a keyboard and a mouse. Output device 308may comprise, for example, a display and/or a printer.

Storage device 304 may comprise any appropriate information storagedevice, including combinations of magnetic storage devices (e.g.,magnetic tape and hard disk drives), optical storage devices such as CDsand/or DVDs, and/or semiconductor memory devices such as Random AccessMemory (RAM) devices and Read Only Memory (ROM) devices, as well asso-called flash memory.

Storage device 304 stores one or more programs for controlling processor300. The programs comprise program instructions that containprocessor-executable process steps of server computer 204, including, insome cases, process steps that constitute processes provided inaccordance with principles of the present invention, as described inmore detail below.

The programs may include an application/program module 310 that allowsFI administrative personnel to set up profiles that are to be stored inthe server computer 204 and/or in a respective one of the FI computers202 in regard to service fees and/or foreign exchange conversion fees tobe charged by the FI in question for remittance services. The programsmay also include an application/program module 312 that allows FIadministrative personnel to establish various rules for remittancetransactions. Such rules may include assignment of fee profiles tocertain classes of remittance transactions.

Still another application/program module 314 stored on the storagedevice 304 may aid FI administrative personnel in managing and trackingapproval at higher levels of rules proposed by lower leveladministrative personnel. Further applications/program modules 316 and318, also stored on the storage device 304, may be useful, respectively,for performing miscellaneous administrative tasks and for implementingdata queries or reports regarding remittance activities by an FI. Asindicated at 320, the storage device 304 may store one or more databasesof information relevant to remittance activities.

In addition to the software programs expressly listed above, the servercomputer 204 may be programmed with other software, such as one or moreoperating systems, device drivers, database management programs,programs to enable the server computer 204 to perform web hostingfunctions, etc.

FIG. 4 is a block diagram representation of a typical one of the sendingFI computers 202 shown in FIG. 2.

In its hardware aspects, the computer 202 may be conventional, andsimilar to the hardware components described above in connection withthe server computer 204. The hardware aspects of the computer 202 willtherefore not be further described, except to mention that the computer202 may include a processor 400 in communication with a communicationdevice 401, a storage device 404, an input device 406, and an outputdevice 408.

The storage device 404 may store an application program 410 that allowsprospective senders of remittances to establish user accounts withrespect to the FI's remittance services. A further application program412, also stored on the storage device 404, may operate to handleparticular remittance transactions. Still another application program414, also stored on the storage device 404, may allow for modificationand management of user accounts. Further, one or more databases 416stored on the storage device 404 may contain data relating to remittancetransactions, user accounts, etc.

In addition to the software programs expressly listed above, thecomputer 202 may be programmed with other software, such as one or moreoperating systems, device drivers, database management programs,programs to enable the computer 202 to perform web hosting functions,etc.

Each of the user computers 206 may be a personal computer or othercomputing device (including, e.g, a mobile telephone), and may includeconventional components such as a CPU, a display, a keyboard and amouse.

FIG. 5 shows a sign-in screen display that may be accessed by anadministrative employee of an FI in connection with the system of FIG.2. As is also the case with the screen displays shown in FIGS. 5A-9,11-14 and 16-30, the screen display of FIG. 5 may be downloaded fromcomputer 204 or from one of the computers 202 in FIG. 2, and displayedon the display screen of a personal computer or terminal operated by theadministrative employee and in communication with the computer 204 or202. At the data entry fields 502, 504 in FIG. 5, the administrativeemployee may enter his/her user ID and PIN, respectively. Uponverification of the user ID and PIN, the screen display shown in FIG. 5Ais presented. This screen display is a main menu page, and includes pulldown menus 510 (“Setup”), 512 (“Rules”), 514 (“Review”), 516 (“Admin”)and 518 (“Reports & Queries”).

Upon pulling down the menu 510, the user sees the menu options “AcquirerProfile”, “Sending Issuers”, “Receiving Issuers”, “Sending Countries”and “Receiving Countries”. If the user selects the “Acquirer Profile”menu option, then the display screen shown in FIG. 6 is provided. Thedisplay screen of FIG. 6 is a data entry screen by which the user maydefine a profile for the sending FI with respect to thepayment-card-based remittance system. In the upper region 602 of thedata entry screen of FIG. 6, the user may enter information such as theFI's name, country of registration, address, ICA and BIN numbers, andcontact information. In a lower region 604 of the data entry screen theuser may enter transaction limit(s) that may apply across alltransactions initiated in the remittance system by the FI.

If the user selects the “Sending Issuers” menu option from pull downmenu 510, then the screen display shown in FIG. 7 is provided. Thescreen display of FIG. 7 allows the user to select from among FIs thatissue payment card accounts. Selection of one of those issuers in FIG. 7means that the FI engaged in the setup procedure is enabled to initiateremittance transactions to be funded from payment card accounts issuedby the selected issuers. At 702 in FIG. 7 there is a data display fieldthat lists the payment card issuers that are available for selection.Data display field 704 lists (none shown in FIG. 7) issuers that havebeen selected. Select/de-select buttons 706 may be actuated by the userto add or remove issuers to/from the “selected” list shown in field 704.

If the user selects the “Receiving Issuers” menu option from pull downmenu 510, then a screen display similar in format to FIG. 7 is shown.The “Receiving Issuers” screen display (not shown) allows the user toselect from among available issuers, where selection of such an issuerenables the FI engaged in the setup procedure to send remittances to theselected issuer.

If the user selects the “Sending Countries” menu option from pull downmenu 510, then the screen display shown in FIG. 8 is provided. In thescreen display of FIG. 8, there may be a pull down menu 802, from whichthe user may select a country from which the FI may initiate remittancetransactions (in some embodiments there may be only one such country).For the selected “sending country” the user may enter, in one or more ofthe data entry fields 804, 806, 808, 810, codes that represent thecurrencies that the remittance sender may use to fund remittancetransactions.

If the user selects the “Receiving Countries” menu option from pull downmenu 510, then the screen display shown in FIG. 9 is provided. In thescreen display of FIG. 9, there may be a column 902 of pull down menus.Each of the pull down menus in column 902 may be used to select arespective country. Selection of a country from one of the menus incolumn 902 indicates that the FI is enabled to send remittances to theselected country. For each of the pull down menus in FIG. 9, there is arow of data entry fields in which the user may enter codes to representcurrencies in which remittances may be disbursed in the respectiveselected country.

Upon pulling down the “Rules” menu 512 (FIG. 5A), the user sees the menuoptions “Service Fees Profile Setup”, “Service Fees Profile Assignment”,“Forex Markup Profile Setup”, “Forex Markup Profile Assignment”,“Transaction Limits Profile Setup” and “Transaction Limits ProfileAssignment”. (As will be appreciated by those who are skilled in theart, “Forex” stands for “foreign exchange”, and a “Forex Markup” is aservice fee charged for converting one currency to another.)

If the user selects the “Service Fees Profile Setup” option from themenu 512, then the process illustrated by the flow chart in FIG. 10 islaunched. (This process may be implemented with software on one or bothof the server computer 204 or the respective FI's computer 202.)

Referring then to FIG. 10, at 1002 in FIG. 10 it is determined whetherthe user has opted to define a fee profile. If so, then step 1004follows. At 1004, a data entry page screen display as shown in FIG. 11is provided. Referring to FIG. 11, the screen display includes an upperportion 1102 and a lower portion 1104.

The upper portion 1102 of the screen display may have several radiobuttons, of which the user may select one to select a name or otherdesignation for the fee profile to be defined by entering data in thelower portion 1104. Thus, the lower portion 1104 is for the user toenter data for defining the fee profile designated in the upper portion1102.

If the user actuates the “Add New” button 1106 in the upper portion1102, then a data entry field (not shown) is added to the lower portion1104. This additional data entry field may be used to enter a name ordesignation for a new profile to be defined with data entry in the lowerportion 1104. In this situation, there may also be a pull down menu orthe like (not shown) from which to select a code to designate thecurrency in which the fees are to be denominated.

Designation of the fee profile to be defined, whether by radio button ordata entry of a new designation, is indicated at 1006 in FIG. 10

Referring again to FIG. 11, the lower portion 1104 of the screen displaymay include four columns of data entry fields, namely, as referenced inFIG. 11, columns 1108, 1110, 1112 and 1114. The data entry fields of thecolumns 1108, 1110, 1112 and 1114 are also arranged in rows, with eachof the rows corresponding to a respective tier of the service feestructure that is to be defined. In each row, the data (if any)displayed in the first column 1108 corresponds to the tier start amount,and the data displayed in the second column 1110 corresponds to the tierend amount. The data in the third column 1112 indicates the amount ofservice fee applicable to the tier in question, and the data in thefourth column 1114 indicates the percentage service fee applicable tothe tier in question, over and above any flat amount fee indicated inthe fourth column 1114.

Returning now to FIG. 10, following step 1006 is a decision block 1008.At 1008, it is determined whether the user has entered (e.g., via thekeyboard of his/her personal computer/terminal) a numerical amount in adata entry field in the second column 1110. If so, then step 1010follows decision block 1008. At step 1010, the display is updated in thedata entry field to reflect the numerical amount that was entered, andin addition the data entry field in the next row and in the first column1108 is automatically populated with the amount that was just entered inthe second column 1110 in the row above the next row. An example of thisis shown in FIG. 12. Specifically (and in comparison to FIG. 11), thedata entry field in the first row and in the second column 1110 hasreceived data entry to define the tier end amount for the first tier as250 Singapore dollars, as indicated at 1202 in FIG. 12. In addition, thedata field in the second row and in the first column 1108 has beenautomatically populated to define the tier start amount for the secondrow (corresponding to the second tier of the fee structure) as 250Singapore dollars, as indicated at 1204 in FIG. 12.

A further tier end amount update/next tier start amount population isillustrated in FIG. 13 (in comparison to FIG. 12). As seen from FIG. 13,the data entry field in the second row and in the second column 1110 hasreceived data entry to define the tier end amount for the second tier as500 Singapore dollars, as indicated at 1302 in FIG. 13. Also, the datafield in the third row and in the first column 1108 has beenautomatically populated to define the tier start amount for the thirdrow (corresponding to the third tier of the fee structure) as 500Singapore dollars, as indicated at 1304 in FIG. 13.

A data entry update for the third tier end amount and automaticpopulation for the fourth tier start amount data field are illustratedrespectively at 1402 and 1404 in FIG. 14.

If no tier end amount data entry occurs at 1008, then another decisionblock 1012 follows decision block 1008. (Alternatively, if a tier endamount data entry did occur at 1008, then decision block 1012 followsstep 1010.) At decision block 1012, it is determined whether the userhas entered (e.g., via the keyboard of his/her personalcomputer/terminal) a numerical amount in a data entry field in the thirdcolumn 1112. If so, then step 1014 follows decision block 1012. At step1014, the data entry field in question is updated to reflect the dataentry, and the corresponding currency amount is assigned as a flatamount service fee to the tier defined by the tier start amount and thetier end amounts indicated in the same row (in the first column 1108 andthe second column 1110, respectively). A change/update to the servicefee amount for the first tier of the fee structure is indicated bycomparing data field 1306 as seen in FIG. 13 with data field 1306 asseen in FIG. 14. Similar changes may of course be made in other rows inthe third column 1112 and/or to add or change a percentage based servicefee by data entry in the fourth column 1114.

If no fee level data entry occurs at 1012, then another decision block1016 follows decision block 1012. (Alternatively, if a fee level dataentry did occur at 1012, then decision block 1016 follows step 1014.) Atdecision block 1016, it is determined whether the user has indicatedthat he/she has completed entering or editing the designated profile.The user may indicate that he/she has completed entering or editing theprofile by actuating the “Proceed” button (reference numeral 1406 inFIG. 14). If the user so indicates, a positive determination is made atdecision block 1016, and step 1018 then follows decision block 1016. Atstep 1018, the service fee profile defined by the data entered at 1008,1012 is stored, for future assignment to certain classes of remittancetransactions, as will be described below.

If a negative determination is made at decision block 1016 (i.e., if theuser has not indicated that he/she has completed data entry for the feeprofile), then the process of FIG. 10 loops back to decision block 1008and decision block 1012, to allow for multiple iterations of enteringtier end amounts and fee level amounts.

Although not expressly indicated in FIG. 10, the user may also escapefrom the process of FIG. 10, without causing the entered data to bestored, by actuating the “Cancel” button 1408 shown in FIG. 14.

Considering again the “Rules” menu 512 (FIG. 5A), if the user selectsthe “Service Fees Profile Assignment” option from the menu 512, then theprocess illustrated by the flow chart in FIG. 15 is launched. (Thisprocess may be implemented with software on one or both of the servercomputer 204 or the respective FI's computer 202.)

Referring then to FIG. 15, at 1502 in FIG. 15 it is determined whetherthe user has opted to assign a fee profile to a class of remittancetransactions. If so, then step 1504 follows. At 1504, a data entry pagescreen display as shown in FIG. 16 is provided. Referring to FIG. 16,the screen display includes an upper portion 1602 and a lower portion1604. In contrast to much of the data entry described with reference toFIGS. 10-14, most if not all of the data entry performed in the processof FIG. 15 (and performed with use of the data entry screen display ofFIG. 16) may be accomplished by interaction with pull down menus. Thescreen display shown in FIG. 16 includes, in the upper portion 1602,four pull down menus 1606, 1608, 1610 and 1612 for defining a class ofremittance transactions to which a service fee profile is to beassigned. The class of transactions may be defined in terms of (a) thecountry from which the remittance is sent (“sender country”), (b) thecurrency in which the remittance is funded (“sender currency”), (c) thecountry to which the remittance is sent (“recipient country”), and (d)the currency in which the remittance is disbursed (“recipientcurrency’). These four parameters may be considered to define a currencyremittance channel. The pull down menu 1606 may be employed to selectthe sender country (although, in some embodiments, the pull down menu1606 may contain only one option, in that the FI in question mayoriginate remittance transactions from only one country—its country ofoperation). The pull down menu 1608 may be employed to select the sendercurrency. The pull down menu 1610 may be employed to select therecipient country. The pull down menu 1612 may be employed to select therecipient currency.

It will be recognized that defining a currency remittance channelinherently includes selecting a pair of currencies, namely the sendercurrency and the recipient currency.

Continuing to refer to FIG. 16, the lower portion 1604 of the screendisplay includes a pull down menu 1614, which may be used to select apreviously stored service fee profile for assignment to the currencyremittance channel defined with the pull down menus 1606-1612.

Referring once more to FIG. 15, following step 1504 is step 1506. Atstep 1506, a currency remittance channel is defined, by the userinteracting with the pull down menus 1606-1612 to select the fourparameters for the currency remittance channel. (As noted before, thefirst parameter—the sender country—may be fixed.) FIG. 17 is a screendisplay that shows a currency remittance channel that has been selected.In the example screen display of FIG. 17, the sender country isSingapore, the sender currency is Singapore dollars, the recipientcountry is Indonesia, and the recipient currency is U.S. dollars.

Referring yet again to FIG. 15, step 1508 follows step 1506. At step1508, the user selects a service fee profile by interacting with thepull down menu 1614. FIG. 18 is a screen display that shows that acertain service fee profile (in this example, the profile previouslydesignated as “Profile 1”) has been selected from the pull down menu1614. Next, at step 1510 in FIG. 15, the user may assign the selectedservice fee profile to the currently defined currency remittance channelby actuating the “Assign” button shown at 1802 in FIG. 18. FIG. 19 isthe screen display that is presented upon actuation of the “Assign”button (seen in FIG. 18, not included in the screen display of FIG. 19).In FIG. 19, the grid of data display fields in the lower portion of thescreen display is employed to present to the user the fee structuredefined in the selected and assigned service fee profile. With the feestructure in front of him/her, the user may confirm the assignment ofthe fee profile to the currency remittance channel by actuating the“Proceed” button 1902. Another button, which is not shown in FIG. 19,may also be present to allow the user to go back to an earlier screen inorder to select a different fee profile for assignment to the currencyremittance channel.

In some embodiments, the assignment of the fee profile to the currencyremittance channel may be tentative or provisional in the sense that itmay require approval from a higher level manager within the FI.

Considering again the “Rules” menu 512 (FIG. 5A), if the user selectsthe “Forex Markup Profile Setup” option from the menu 512, then aprocess similar to that of FIG. 10 is launched and a data entry screendisplay as in FIG. 20 is provided. Data entry for defining a foreignexchange conversion fee profile may be performed by interaction with thedata entry screen display of FIG. 20 and in a similar manner to theservice fee profile definition process described above with reference toFIGS. 10-14. In view of the above explanation of FIGS. 10-14 and thesimilar operability of FIG. 20 in comparison with FIG. 11, those ofordinary skill in the art will not require a further explanation of FIG.20 and the associated process for defining a foreign exchange conversionfee profile.

Again with regard to the “Rules” menu 512, if the user selects the“Forex Markup Profile Assignment” option from menu 512, then a processsimilar to that of FIG. 15 is launched and a data entry screen displayas in FIG. 21 is provided. Data entry for assigning a foreign exchangeconversion fee profile to a class of transactions may be performed byinteraction with the data entry screen display of FIG. 21 and in asimilar manner to the service fee profile assignment process describedabove with reference to FIGS. 15-19. One difference between the foreignexchange conversion fee profile assignment process and the service feeprofile assignment process is that the former may only require selectionof two currencies (the sender currency and the recipient currency) whereas the latter also may require selection of the sender country and therecipient country. Otherwise, the similarity between the two profileassignment processes is such that FIG. 21, taken with the abovediscussion of FIGS. 15-19, is sufficient to make the foreign exchangeconversion fee profile assignment process understood by those who areskilled in the art.

Referring once more to the “Rules” menu 512, if the user selects the“Transaction Limits Profile Setup” option from menu 512, then a dataentry screen display as in FIG. 22 is provided. It will be noted that anupper portion 2202 in FIG. 22 allows for designation of a newtransaction limits profile to be defined or an existing transactionlimits profile to be edited. A lower portion 2204 of FIG. 22 mainlycomprises a grid of data entry fields that the user may employ to enterlimits on transactions in a number of different currencies. The limitsmay be defined in terms of a maximum number of transactions per day,maximum currency amount per transaction and/or maximum cumulativetransaction amounts over one or more periods of time.

Again with respect to the “Rules” menu 512, if the user selects the“Transaction Limits Profile Assignment” option from menu 512, then adata entry screen display as in FIG. 23 is provided. An upper portion2302 of the screen display of FIG. 23 includes one or more data entryfields and/or pull down menus that the user may employ to identify acustomer or class of customers to which a transaction limits profile isto be assigned. The lower portion 2304 of the screen display of FIG. 23may include a pull down menu 2306 by which the user may select apreviously stored transaction limits profile to be assigned to thecustomer(s) or class(es) of customers defined in the upper portion ofthe screen display.

Upon pulling down the “Review” menu 514 (FIG. 5A), the user sees themenu options “Pending Requests”, “Approved Requests”, “RejectedRequests” and “Suspect Customers”. If the user selects the “PendingRequests” option, then a screen display as shown in FIG. 24 may beprovided. The user may select one of the radio buttons in FIG. 24 andthen click “Proceed” to call up a report of (a) service fee profileassignments awaiting higher level approval, (b) foreign exchangeconversion fee profile assignments awaiting higher level approval, or(c) transaction limits profile assignments awaiting higher levelapproval. Thus the display screen of FIG. 24 may be useful to the userin managing the approval process for profile assignments.

If the user selects the “Approved Requests” or “Rejected Requests”options in menu 514 he/she may be provided with a screen display similarto FIG. 24, for allowing the user to call up reports concerning approvedor rejected profile assignments.

“If the user selects the “Suspect Customers” option in menu 514, then ascreen display like FIG. 25 may be provided. The screen display of FIG.25 may present a report that individually lists customers who haveapparently come up on anti-money laundering or antiterrorism watchlists, or the like. The screen display may also include a drop down menu(not shown) for each listed customer, to allow the user to select astatus for the customer such as “Blocked” (i.e., prevented frominitiating and/or receiving remittances) or “Active” (i.e., not“Blocked”).

Returning now to FIG. 5A, if the user pulls down the “Admin” menu 516,the following menu options are available: “User Rights”, “Uploads”, and“Add Suspect Customer”. If the user selects the “User Rights” option,then a screen display like FIG. 26 is provided. FIG. 26, in anessentially conventional manner, allows a supervisory user to defineaccess rights for various registered users of the system.

If the user selects the “Uploads” option from menu 516, then a screendisplay like FIG. 27 is provided. The screen display 27 may bemanipulated by the user to select files for uploading.

If the user selects the “Add Suspect Customer” option from menu 516,then a screen display like FIG. 28 is provided. The user may employ thescreen display of FIG. 28 to launch a search for certain customers byname, by address, etc., and then may use an additional screen display(not shown) to select one or more customers from the search results to alist of suspect customers.

Referring once more to FIG. 5A, if the user pulls down the “Reports &Queries” menu 518, the following menu options are available: “Queries”and “Reports”. If the user selects the “Queries” option, then a queryform (screen display) like FIG. 29 is provided to allow the user toquery a transaction database as to one or more particular customersand/or one or more particular transactions. If the user selects the“Reports” option, then a screen display like FIG. 30 is provided, toallow the user to select a report for printing and/or export to anexternal spreadsheet program.

The discussion will now turn, from the FI administrative toolsillustrated in FIGS. 5-30, to aspects of a customer user interface, asrepresented in FIGS. 31-41.

FIG. 31 shows a sign-in screen display that may be accessed by acustomer (or prospective customer) of an FI in connection with thesystem of FIG. 2. As is also the case with the screen displays shown inFIGS. 32-41, the screen display of FIG. 31 may be downloaded from acomputer 202 (FIG. 2) operated by or on behalf of the FI, and displayedon the display screen of a personal computer operated by the customerand in communication with the computer 202. In FIG. 31, a newprospective customer may actuate a “New User Registration” button 3102to access a screen display like that shown in FIG. 32. The prospectivecustomer may then use the data entry fields in the screen display ofFIG. 32 to begin registering with the system by entering personalinformation. Once the personal information (including mobile telephonenumber) has been entered, and the customer has indicated that the dataentry is complete, the system may then automatically place a telephonecall to the customer's mobile telephone to confirm at least that thecustomer really is in possession of the telephone that has been assignedthe mobile telephone number that the customer has entered. After thisprocedure has been successfully completed, the customer has beenregistered in the system as a customer-user and is then prompted toproceed with registering his/her payment card account that is to be usedfor funding remittance transactions. A data entry display screen thatthe customer may use to identify the funding account is shown in FIG.33. It will be observed that the funding account may be a payment cardaccount such as an account issued by the FI under the “MasterCard”brand.

Once the customer has entered the funding account information, he/shemay next be prompted to proceed with storing information that identifiesa recipient to whom the customer intends to send remittances via thesystem. A data entry display screen that may be used for this purpose isshown in FIG. 34. Part of the information required to complete thisdisplay screen includes the payment card account of the recipient, sothat remittances to the designated recipient may be routed as “paymenttransactions” in a payment card system.

Returning to FIG. 31, the customer (now assumed to be a previouslyregistered customer) may use data entry fields 3104, 3106 to enterhis/her user identification (e.g., his/her mobile telephone number) andPIN. Upon verification of the user ID and PIN, the screen display shownin FIG. 34A is presented. This screen display is a main menu page, andincludes options 3402 (“Send”), 3406 (“Estimate”) and 3408 (“MyAccount”), with the latter being a pull down menu.

If the customer pulls down the “My Account” menu 3408, the menu optionsthat are displayed may be “Personal Details”, “Mobile Phone”, “PIN”,“Funding Accounts”, “Receiver Details” and “Transactions”. Any theseoptions may be selected by the customer for the purpose of updatinginformation stored in the FI computer 202 relative to the customer'sonline user account. If the customer selects the “Personal Details”option, then a data entry form (which is not shown) is provided to allowthe customer to enter a change of address or otherwise to updatepersonal information.

If the user selects the “Mobile Phone” option, then a data entry form(which is not shown) is provided to allow the customer to enter his/herupdated mobile telephone number. In some embodiments, the systemautomatically calls back the new mobile telephone number to confirm thecustomer's possession of the mobile telephone in question before theupdating operation is allowed to be completed.

If the customer selects the “PIN” option, then a data entry form (whichis not shown) is provided to allow the customer to change his PIN.

If the customer selects the “Funding Accounts” option, then a displayscreen as shown in FIG. 35 is provided. As will be appreciated fromexamining FIG. 35, this screen display allows the customer to add one ormore new accounts (either payment card accounts or bank accounts) to alist of the customer's accounts that are available to fund remittancetransactions. The screen display of FIG. 35 also allows the customer todelete one or more accounts from the list of funding accounts.

If the customer selects the “Receiver Details” options, then a displayscreen as shown in FIG. 36 is provided. As will be appreciated fromexamining FIG. 36, this screen display allows the customer to add anadditional recipient's account to the list of accounts to which thecustomer may send remittances. The screen display of FIG. 36 also allowsthe customer to delete one or more accounts from the list of recipients'accounts.

If the customer selects the “Transactions” option, then a search inquiryscreen display (not shown) is provided to allow the customer to submit asearch query to locate information relating to one or more of thecustomer's previous remittance transactions. FIG. 37 is an exampleresults page that may be provided in response to a search query of thetype that was just described.

Referring again to FIG. 34A, if the customer wishes to make aremittance, he/she may select the “Send” option 3402, in which case ascreen display as shown in FIG. 38 may be provided. The screen displayof FIG. 38 includes a list 3802 of the customer's available fundingaccounts, and a list 3804 of recipients that the customer has previouslyentered into the system. The customer may select a radio button from thefirst list 3802 to select a funding account for the desired remittance.The customer may select the recipient for the remittance by selecting aradio button from the second list 3804. By entering a currency amount inthe data entry field 3806, the customer may set the amount of money tobe transferred to the selected recipient. By clicking on the “GetEstimate” button 3808, the customer can obtain an estimated summary ofthe cost and outcome of the desired remittance, as presented at 3902 inFIG. 39. The sender currency may be selected automatically by the systembased on the currency in which the funding account is denominated, andlikewise the recipient currency may be selected automatically by thesystem based on the currency in which the selected recipient account isdenominated. Based on these two currencies and the sender and recipientcountries, the system may access the applicable service fee profile(s)for use in determining the service fee and the foreign exchange markup.The base currency exchange rate may be determined from a daily fixobtained from a source of exchange rate information.

Upon the customer actuating the “Proceed” button 3904 in FIG. 39, theconfirmation screen display shown in FIG. 40 is provided. The customermay then cause the desired remittance transaction to be executed byactuating the “Proceed” button 4002 in FIG. 40. Upon the customer doingso, and assuming everything is in order, then the remittance transactionis processed, and the screen display of FIG. 41 is provided to confirmsuccessful processing of the remittance transaction. (In someembodiments, after the customer actuates the “Proceed” button, the FIcomputer may initiate a telephone call to the customer's mobiletelephone, and require the customer to enter a supplementary PIN or thelike, before executing the remittance transaction.)

Upon the customer's actuation of the “Proceed” button 4002 in FIG. 40,the customer FI (the sending FI) initiates a payment transaction in thepayment card system to implement the remittance requested by thecustomer, with the payment transaction to be charged to the customer'sselected payment card account and to be routed to the selectedrecipient's payment card account (alternatively a remittance to anon-payment card account may occur, as will be described below inconnection with FIGS. 42-46). Conventional processing of a paymenttransaction in the payment card system may take place, and in additionthe recipient may be notified upon completion of the transaction whenthe transferred funds are available in the recipient's account.

According to some aspects of the invention, the recipient's accountselected by the customer need not be a payment card account. Systems andprocesses will now be described, with reference to FIGS. 42-46, in whicha payment card system is employed for remittances to be received innon-payment-card accounts.

FIG. 42 is a block diagram that illustrates a remittance system 4200 inwhich an international payment card system 4202 (akin to payment system102, FIG. 1) is used to make a remittance into a bank account(recipient's account) 4204 that is not a payment card account. As theremittance system 4200 is illustrated in FIG. 42, only the systemcomponents that may be involved in a single remittance transaction areshown. Nevertheless, in practice, there may be a large number ofadditional system components, as will be described in further detailbelow.

The remittance system 4200 may include a personal computer 206 that isoperated by a customer of an FI to initiate a remittance transaction. Inparticular, the personal computer 206 may be used to access a remittanceservices website 4206 hosted by, e.g., the computer 202 (FIG. 2)operated by or on behalf of the FI which issued the customer's paymentcard account from which the customer wishes to fund the remittancetransaction. The personal computer 206 may access the remittanceservices website 4206 via a network 208 such as the Internet. Theinteraction of the customer (via the customer's PC 206) with theremittance services website 4206 may be via a user interface like thatillustrated above in FIGS. 31, 34A and 38-41. For present purposes, itwill be assumed that the customer has selected as the recipient'saccount for the remittance transaction a bank account that is located ina foreign country (foreign bank) and that is not a payment card account.

The remittance system 4200 may also include a server computer 4208 thathandles remittance transaction requests forwarded from the remittancewebsite 4206/FI computer 202. The remittance transaction requestsinitiated by FI customers may be sent from the FI computer to theremittance request handling server computer 4208 via a datacommunication network which may be the Internet 208 or which may be aseparate (e.g., private) network, which is not separately shown. Theremittance request handling server computer 4208 may be operated by oron behalf of the payment card association that operates the paymentsystem network 4202.

The remittance request handling server computer 4208 is in communicationwith the payment system network 4202, via a payment system gatewaycomputer 4210, for the purpose for initiating payment card systempayment transactions to be routed via the payment system network 4202.Block 4212 in FIG. 42 represents both (a) an Agent Bank appointed by thepayment card association in the country in which recipient's bankaccount is located, and (b) a computer operated by or on behalf of theAgent Bank. A settlement account 4214 is maintained by the Agent Bank toreceive funds via payment transactions in the payment system network4202 and to disburse the funds by suitable transfer mechanisms to therecipients' accounts. Thus the settlement account 4214 may serve ineffect as the target payment card account for payment transactionsrouted by the payment system network 4202. The Agent Bank also receives(e.g., on a daily basis) a file 4216 of funds transfer instructions fromremittance request handling server computer 4208.

In cases where the recipient's account 4204 is maintained (as depictedin FIG. 42) with a bank 4218 that is not the Agent Bank 4212, theremittance is completed with an interbank electronic funds transfer(EFT) 4220 from the settlement account 4214 into the recipient's account4204. In the special case when the recipient's account is at the AgentBank, the remittance is completed with an intrabank EFT 4222, which isindicated in phantom.

To consider more broadly the remittance system 4200, it should beunderstood that there may be many (potentially hundreds of thousands ormillions) of user computers (beyond the one user computer 206 which isshown in FIG. 42) that may potentially participate in the remittancesystem, and in fact a considerable number of user computers maysimultaneously access the remittance system 4200 for the purpose ofinitiating remittance transactions. There may be only one remittancewebsite 4206, or alternatively, there may be a separate website for eachcountry or region from which remittances may be sent through the system4200 and/or a separate website for each sending FI. Similarly, there maybe only one remittance request handling server computer 4208, or theremay be a number of such computers, each serving a respective country orregion and/or backing up another such computer. There may also be anumber of payment system gateways 4210. Preferably, but not necessarily,the payment system network 4202 may be a single worldwide payment systemsuch as the Banknet system operated by MasterCard International Inc.,the assignee hereof.

Continuing to consider the remittance system 4200 from a broad point ofview, there may be a respective Agent Bank 4212 and a respectivesettlement account 4214 in each country to which remittances may be sentvia the system 4200. Moreover, there may be a considerable number ofrecipient banks 4218 in each country to which remittances may be sentvia the system 4200. For example, the recipient banks may include everybank that participates in an EFT or ACH (automated clearing house)system with the Agent Bank in a given country.

FIG. 43 is a block diagram that illustrates an example embodiment of theremittance request handling server computer 4208 shown in FIG. 42.

In its hardware aspects, the remittance request handling server computer4208 may be conventional, and similar to the hardware componentsdescribed in connection with the computers described above withreference to FIGS. 3 and 4. The hardware aspects of the remittancerequest handling server computer 4208 will therefore not be furtherdescribed, except to mention that the remittance request handling servercomputer 4208 may include a processor 4300 in communication with acommunication device 4301, a storage device 4304, an input device 4306,and an output device 4308.

The storage device 4304 may store one or more application programs,represented by blocks 4310, 4312 and 4314, and that include softwareprogram instructions to control the processor 4300. For example, program4310 may program the processor 4300 to handle incoming requests forremittance transactions received via the remittance website 4206 (FIG.42). Program 4312 may program the processor 4300 to respond toremittance transaction requests by initiating payment transactions to berouted via the payment system network 4202 to the respective Agent Bank4212 and settlement account 4214 in the country to which the remittanceis to be sent. Program 4314 may program the processor 4300 to prepareand transmit files of instructions to the Agent Banks in the variouscountries to perform funds transfers to the recipients' accounts 4204.Further, one or more databases 4316 stored on the storage device 4304may contain data relating to remittance transactions, instructionsissued, etc. (Although the programs 4310, 4312 and 4314 are presented asseparate applications, in practice any two or more of them may becombined into a single application.)

In addition to the software programs expressly listed above, theremittance request handling server computer 4208 may be programmed withother software, such as one or more operating systems, device drivers,database management programs, etc.

FIG. 44 is a block diagram that illustrates an example embodiment of theAgent Bank computer 4212.

In its hardware aspects, the Agent Bank computer 4212 may beconventional, and similar to the hardware components described inconnection with the computers described above with reference to FIGS. 3,4 and 43. The hardware aspects of the Agent Bank computer 4212 willtherefore not be further described, except to mention that the AgentBank computer 4212 may include a processor 4400 in communication with acommunication device 4401, a storage device 4404, an input device 4406,and an output device 4408.

The storage device 4404 may store one or more application programs,represented by blocks 4410, 4412 and 4414, and that include softwareprogram instructions to control the processor 4400. For example, program4410 may program the processor 4400 to manage the settlement account4214 (FIG. 42), including responding to and receiving paymenttransactions routed to the settlement account 4214 via the paymentsystem network 4202, and disbursement of funds from the settlementaccount 4214. Program 4412 may program the processor 4400 to receive andinterpret funds transfer instruction files received from the remittancerequest handling server computer 4208. Program 4414 may program theprocessor 4400 to interact with an EFT network (not separately shown) toimplement electronic funds transfer from the settlement account 4214 tothe recipients' accounts (e.g., account 4204 shown in FIG. 42). Further,one or more databases 4416 stored on the storage device 4304 may containdata relating to transfers of funds into and out of the settlementaccount 4214. (Although the programs 4410, 4412 and 4414 are presentedas separate applications, in practice any two or more of them may becombined into a single application.)

In addition to the software programs expressly listed above, the AgentBank computer 4212 may be programmed with other software, such as one ormore operating systems, device drivers, database management programs,etc.

FIG. 45 is a flow chart that illustrates a process that may be performedby the remittance request handling server computer 4208

At 4502 in FIG. 45, the remittance request handling server computer 4208determines whether a remittance request received via the remittancewebsite 4206 is to be directed to a recipient's account which is not apayment card account. If so, then step 4504 follows 4502. (In the casewhere the recipient's account indicated in the remittance request is apayment card account, then the remittance request handling servercomputer 4208 may initiate a conventional payment card system paymenttransaction to be routed to the recipient's payment card account, asdescribed in the above-mentioned, commonly assigned U.S. patentapplication Ser. No. 11/836,984.)

At step 4504, the remittance request handling server computer 4208initiates a payment transaction to be routed via the payment systemnetwork 4202 to the settlement account 4214 in the country in which therecipient's account 4204 is located. The payment transaction may befunded from the sender's payment card account designated in theremittance request. Any currency translation required in connection withthe payment transaction may be performed in a conventional manner by theremittance request handling server computer 4208. At substantially thesame time, and as indicated at 4506, the remittance request handlingserver computer 4208 stores an instruction to be sent later to the AgentBank computer 4212 to instruct the Agent Bank computer 4212 to transferthe proceeds of the payment transaction initiated at 4504 from thesettlement account 4214 to the recipient's account 4204. Thereafter, andas indicated at 4508, the instruction stored at 4506 is sent to theAgent Bank computer 4212 as part of a file 4224 (FIG. 42) of fundstransfer instructions. For example, this may be done as part of anend-of-day batch process performed by the remittance request handlingserver computer 4208. In practice, the remittance request handlingserver computer 4208 may send such a funds transfer instruction filedaily to the respective Agent Bank computer 4212 for each country towhich the remittance request handling server computer 4208 sendsremittances by the process illustrated in FIG. 42.

FIG. 46 is a flow chart that illustrates a process that may be performedby the Agent Bank computer 4212.

At 4602, the Agent Bank computer 4212 receives in the settlement account4214 payment transactions routed to the settlement account 4214 by theremittance request handling server computer 4208 via the payment systemnetwork 4202. This may take place on an ongoing basis and may includesending of acknowledgement messages or the like in connection with thepayment transactions, as would conventionally be performed by the issuerof the recipient's payment card account in the case of a conventionalpayment transaction.

At 4604, the Agent Bank computer 4212 receives from the remittancerequest handling server computer 4208 an instruction file 4224 (FIG. 42)that instructs the Agent Bank computer 4212 to execute funds transfersto disburse the funds received in the settlement account 4212 via thepayment transactions received therein in step 4602. Then for eachinstruction (as indicated at 4606) in the instruction file 4224, theAgent Bank computer 4212 determines, at 4608, whether the recipient'sbank account designated in the current instruction is at a bankdifferent from the Agent Bank or is at the Agent Bank. If therecipient's bank account is at a different bank (bank 4218, FIG. 42),then as indicated at 4610, the Agent Bank computer 4212 executes aninterbank EFT to transfer the proceeds of the remittance to therecipient's account 4204. (Alternatively, in at least some cases, thetransfer to the recipient's bank 4218 may be via an ACH transaction.)

However, if the Agent Bank computer 4212 determines at 4608 that therecipient's bank account designated in the current instruction is at theAgent Bank, then as indicated at 4612, the Agent Bank computer 4212executes an intrabank EFT to transfer the proceeds of the remittance tothe recipient's account at the Agent Bank.

With the remittance process just described with reference to FIGS.42-46, a recipient who does not have a payment card account maynonetheless receive remittances that utilize the highly efficient fundstransfer capabilities of an international payment card system like thatoperated by the assignee hereof.

In some embodiments of the “direct-to-bank” remittance system depictedin FIG. 42, there may be, as noted above, a number of remittance requesthandling server computers 4208—one for each country or region in thesystem, for example. Although FIG. 42 suggests that each remittancerequest handling server computer 4208 separately sends an EFTinstruction file 4224 to the respective Agent Bank computer 4212 in eachother country, in practice at least some of the separate EFT instructionfiles 4224 directed to a given Agent Bank computer 4212 may beaggregated at a central processing facility (not shown) so that eachAgent Bank computer 4212 may receive only one EFT instruction file 4224rather than a separate EFT instruction file 4224 originating from eachremittance request handling server computer 4208.

In the above discussion of FIGS. 42 and 45 it has been assumed that thesource of funds for the “direct-to-bank” transfer was the sender'spayment card account. Alternatively, however, the source of funds may bea bank account belonging to the sender that is not a payment cardaccount. To accommodate this alternative, the remittance requesthandling server computer 4208 may be directly interfaced to an internetbanking system (not shown) that is operated by the sender's bank.

FIG. 47 is a flow chart that illustrates a process that may be performedby a financial institution computer 104 or 202 in the system of FIGS. 1and/or 2.

At 4702 in FIG. 47, a list of individuals, including their names andpossibly also their residence addresses, is downloaded to the financialinstitution computer 104 or 202. The list may have been developed by alaw enforcement agency as a compilation of names of individuals who arebelieved to be actually or potentially involved in transfers of fundsfor illicit purposes, and thus who should be prevented from usingbanking facilities for such purposes. This list will hereinafter bereferred to as a “suspect persons list”.

At 4704, the financial institution computer 104 or 202 determineswhether it has received data to update the suspect persons list. If so,the financial institution computer 104 or 202 updates the suspectpersons list, as indicated at 4706. Following 4706, or directlyfollowing 4704 if no update is received, is decision block 4708. At 4708it is determined whether the financial institution computer 104 or 202has received a request to perform a remittance transaction. If not, thenthe process of FIG. 47 loops back to 4704.

It will be appreciated that if a request for a remittance transaction isdetermined at 4708 to have been received, then the request wouldoriginate from a sender who is a customer of the financial institutionthat operates the computer 104 or 202, and the request would alsospecify a recipient, presumably one who has previously been entered inthe sender's remittance website user account (e.g., as per FIG. 36, asdiscussed above).

If a positive determination (i.e. remittance request received) is madeat 4708, then decision block 4710 follows 4708. At 4710, the financialinstitution computer 104 or 202 accesses the suspect persons list (ascurrently updated) to determine whether either one of the sender or therecipient is currently listed on the suspect persons list. If not, thenthe financial institution computer 104 or 202 proceeds to execute therequested remittance transaction, as indicated at 4712 (assuming thatthe sender's account is in a condition to support the transaction andassuming that all else is in order). However, if either the sender orrecipient is on the suspect persons list, then the financial institutioncomputer 104 or 202 declines to perform the requested remittancetransaction, as indicated at 4714. Following either 4712 or 4714, theprocess of FIG. 47 loops back to 4704.

As a result of the process of FIG. 47, for each requested remittancetransaction, the financial institution computer 104 or 202 checks thesuspect persons list for the presence of the sender's and therecipient's name on the list in real time after receiving the requestfor the transaction and before executing the remittance transaction.More specifically, the financial institution computer 104 or 202 maycompare the sender and the recipient with the suspect persons list inreal time with respect to each request for a remittance transaction(also referred to as “funds transfer requests”). In this way, thefinancial institution computer 104 or 202 may perform very effectivelyin excluding suspect persons from utilizing the remittance system. Itwill be appreciated that the financial institution computer 104 or 202may loop through the process of FIG. 47 many times, executing step 4710with respect to each one of numerous remittance requests.

In at least some of the screen displays presented in the appendeddrawings, there are button portions or regions, also referred to as“buttons”. It should be understood that, in accordance with conventionalpractices, such buttons may be actuated by suitably operating a pointingdevice such as a mouse by positioning a cursor (not shown) on the buttonwhile clicking a button on the pointing device. Such an operation issometimes referred to as “clicking” on the button region of the screendisplay. The pointing device may be one of the computer input devicesshown in the various computer block diagrams included in the drawings,or may be a component of a user computer shown in the drawings. It willalso be appreciated that entry of data may be accomplished by using acomputer keyboard (also one of the computer input devices) after using apointing device to position a cursor in the desired data entry fieldsamong the data entry fields shown in the appended screen displaydrawings.

As used herein and in the appended claims, “displaying” a screen displayincludes downloading a webpage from a server computer for display on aclient computer.

It is noted that “payment transaction” is a term of art in the field ofpayment card systems, and refers to a transaction in which—incontradistinction to a purchase transaction—funds flow from an acquirerto an issuer as a credit to a payment card account issued to the issuer.In this context, the sending FI may be considered to be an acquirer andthe receiving FI may be considered to be an issuer.

As used herein and in the appended claims, a “service fee” includes aflat fee and/or a percentage-based fee and/or a combination thereofand/or a foreign exchange markup.

The flow charts and descriptions thereof herein should not be understoodto prescribe a fixed order of performing the method steps describedtherein. Rather the method steps may be performed in any order that ispracticable.

As used herein and in the appended claims, the term “payment cardaccount” includes a credit card account or a deposit account that theaccount holder may access using a debit card. The term “payment cardaccount number” includes a number that identifies a payment card accountor a number carried by a payment card, or a number that is used to routea transaction in a payment system that handles debit card and/or creditcard transactions. The term “payment card” includes a credit card or adebit card.

Although the present invention has been described in connection withspecific exemplary embodiments, it should be understood that variouschanges, substitutions, and alterations apparent to those skilled in theart can be made to the disclosed embodiments without departing from thespirit and scope of the invention as set forth in the appended claims.

1. A method comprising: receiving a funds transfer request, the requestspecifying a transaction amount, a destination bank account and a sourceaccount; and responding to the funds transfer request by: initiating apayment transaction to transfer the transaction amount from the sourceaccount to a payment card system settlement account that was establishedby a payment card system with an agent bank; and issuing an instructionfor the agent bank to transfer the transaction amount from thesettlement account to the destination bank account.
 2. The method ofclaim 1, wherein the destination bank account was established at a bankthat is different from the agent bank.
 3. The method of claim 1, whereinthe funds transfer request is received via the Internet.
 4. The methodof claim 3, wherein the funds transfer request is received via a websiteoperated by or on behalf of a bank that issued the source account. 5.The method of claim 1, wherein the payment transaction is to be routedto the payment card system settlement account via the payment cardsystem.
 6. The method of claim 1, wherein: the source account is locatedin a first country; and the settlement account and the destination bankaccount are located in a second country that is different from the firstcountry.
 7. The method of claim 1, wherein the source account is apayment card account.
 8. A method comprising: receiving, in a paymentcard system settlement account established by a payment card system withan agent bank, funds corresponding to a plurality of paymenttransactions implemented via the payment card system; receiving a fileof funds transfer instructions for disbursing to destination bankaccounts the funds corresponding to the plurality of paymenttransactions; and making funds transfers from the settlement account tothe destination bank accounts in accordance with the received file offunds transfer instructions.
 9. The method of claim 8, wherein at leastsome of the destination bank accounts were established with the agentbank.
 10. The method of claim 8, wherein at least some of thedestination bank accounts were not established with the agent bank. 11.The method of claim 8, wherein at least some of the funds transfers areelectronic funds transfers.
 12. The method of claim 11, wherein some ofthe funds transfers are automated clearing house transactions.
 13. Themethod of claim 8, wherein at least some of the funds transfers areautomated clearing house transactions.
 14. The method of claim 8,wherein the file of funds transfer instructions is received from acomputer operated by the payment card system.
 15. A method comprising:receiving, in a payment card account system settlement accountestablished by a payment card system with an agent bank, a transfer of atransaction amount, said transfer implemented as a payment transactionin the payment card system; receiving, at the agent bank, an instructionto transfer the transaction amount from the settlement account to adestination bank account; and responding to the instruction and to thepayment transaction by transferring the transaction amount from thesettlement account to the destination bank account.
 16. The method ofclaim 15, wherein the agent bank transfers the transaction amount to thedestination bank account via an interbank electronic funds transfer. 17.The method of claim 15, wherein the agent bank transfers the transactionamount to the destination bank account via an automated clearing housetransaction.
 18. The method of claim 15, wherein: the destination bankaccount was established with the agent bank; and the agent banktransfers the transaction amount to the destination bank account via anintrabank electronic funds transfer.
 19. The method of claim 15, whereinthe instruction is received from a computer operated by the payment cardsystem.
 20. The method of claim 19, wherein the instruction is receivedas part of a file that includes a plurality of other transferinstructions.
 21. The method of claim 15, wherein the instruction isreceived as part of a file that includes a plurality of other transferinstructions.